1. Field of the Invention
The invention relates in general to a method for file accessing, and more particular to a method for speeding up file accessing to design databases for integrated circuits (ICs).
2. Description of the Prior Art
Design databases for electronic design automation (EDA) tools typically store design units on a file basis, that is, one design unit takes one disk file to store. Furthermore, there is some kind of correlation between a design unit name and its corresponding disk file name. There are some immediate advantages using this scheme.
For example, users can use operating system's (OS's) shell commands, such as “ls” on UNIX, to see the design files underneath a design library and to get a feel for how many design units there are, what their names are, etc. Also, using this scheme, the design database manager can take advantage of the services that the OS's file system offers, for example, file locking and file renaming.
Performance-wise, this scheme is normally acceptable because even though modern day's IC designs can be very large, the number of distinct design units is normally manageable. Taking OpenAccess, an industrial standard of electronic design database from Silicon Integration Initiative (Si2) organization, as an example, there are two kinds of storage schemes offered by OpenAccess, namely DMFileSys and DMTurbo; and both of them use the same one-design-unit-in-one-disk-file scheme.
However, during the last stage of integrated circuit (IC) design process as well as in the early stage of IC manufacturing process, there may be a need to “uniqueify” a design. This is the step in which a distinct design unit is created for each and every design unit instance. This can result in a huge number of design units in a design library, say, in the range of hundreds of thousands or more.
Please refer to FIG. 1A which shows an example of directory tree used by OpenAccess DMFileSys data manager to implement a design library. A design unit in OpenAccess is called a cellview. Each cellview, in DMFileSys mode, takes at least two levels of sub-directories and two files therein to implement. The first-level sub-directory is right underneath the root directory of the library, and the name of the sub-directory follows the cell name part of the cellview. Right underneath the cell sub-directory is a second-level sub-directory for the view name part of the cellview. The view sub-directory includes two files: master.tag and layout.oa. The master.tag is a text file that describes the name of the primary database file in the sub-directory; the layout.oa is the layout view for the design unit. In DMFileSys, therefore, if there are N cellviews in a design library, it will take 2N directories and 2N files to implement.
Please further refer to FIG. 1B which demonstrates another example of directory tree structure in OpenAccess used by a data manager called DMTurbo. In DMTurbo, there is an XML file, called lib.xml, in the library directory. For each cellview in the design library, a separate disk file is created in the library directory for the cellview. The mapping of a cellview name to its corresponding file name is described in lib.xml. As a result, in DMTurbo, if there are N cellviews in a design library, there will be (N+1) files in the library directory—the number of directories and files on the disk is substantially smaller than that of DMFileSys, but which still incurs large amounts of overhead when the number of cellviews is large.
The one-file-per-design-unit scheme will therefore create a huge number of files on disk in a design database. Consequently, performance of EDA tools will come to a halt when they have to access these kinds of databases.
Therefore, what is needed is an efficient data access scheme without using a large number of files or directories in order to speed up data access.